The Amulet Prototype-Instance Framework

Amulet is a new kind of object-oriented framework for user interface development that is based on a prototype-instance object system instead of the conventional class-instance object system. In a prototype-instance object system, there is no concept of a “class” since every object can serve as a prototype for other objects, and any instance can override any methods or data values. Amulet is also differentiated by high-level encapsulations of interactive behaviors, and by the ubiquitous use of constraints, which are relationships that the programmer declares once and then are enforced by the system. The result is that programs written using the Amulet framework have a different style than those written with conventional frameworks. For instance, Amulet applications are typically constructed by combining instances of the built-in objects, rather than by subclassing the built-in classes or writing methods. Amulet is written in C++ and is portable across Windows NT and 95, Unix X/11, and the Macintosh. Copyright © 1998 -Carnegie Mellon University This is a revision of: Brad A. Myers, Richard G. McDaniel, Robert C. Miller, Alan Ferrency, Andrew Faulring, Bruce D. Kyle, Andrew Mickish, Alex Klimovitski, and Patrick Doane “The Amulet Environment: New Models for Effective User Interface Software Development,” IEEE Transactions on Software Engineering. vol. 23, no. 6. June, 1997. pp. 347-365. This research was sponsored by NCCOSC under Contract No. N66001-94-C-6037, Arpa Order No. B326. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of NCCOSC or the U.S. Government. The Amulet Framework 1 Myers Object-Oriented Application Frameworks Creating user interface software has proven to be very difficult and expensive, because it is often large and complex, and challenging to implement, debug, and modify. Most of today’s application frameworks for user interfaces still leave far too much of the application to the programmer. The Amulet user interface development framework tries to overcome this problem by supplying high-level support for the insides of application windows, which most other frameworks ignore. For example, whereas most frameworks do a good job of managing the creation of windows and the main menus, they leave the contents of the window to be programmed at the low-level window manager level, accepting events like “mouse left-button down at 30,50” and using routines like “draw-line.” In contrast, Amulet supplies high-level support for the graphics and interactive behaviors of application-specific objects. The result is that many behaviors, such as creating, moving, selecting, and manipulating objects, cut/copy/paste, save and load, undoing of operations, etc., can often be incorporated into applications without writing any methods at all. A key reason that Amulet provides a high level of support is that all of the user interface objects are available at run-time for inspection and manipulation through a standard protocol. This allows high-level, built-in utilities to be provided which, in other toolkits and frameworks, must be re-implemented for each application. For example, the graphical selection handles widget can get the list of objects in a window, find out which ones are graphical, and move and resize a selected object, all using standard protocols, even if the objects are custom-created and application-specific. The result is that creating applications in Amulet is quite different than in other frameworks. In fact, much of Amulet programming is done without writing methods (Myers 1992), but instead by creating instances of built-in objects, setting their properties, and combining them into groups. In addition to incorporating innovations into its own design, Amulet has an open architecture to enable user interface researchers and developers to easily investigate their own innovations. For example, Amulet is the first system that supports multiple constraint solvers operating at the same time, so that researchers might be able to investigate new kinds of constraint solvers. The undo model also supports new designs. The “widgets” (the UNIX name for elements of the toolkit, like scrollbars, buttons and menus; sometimes called “controls” on the PC) are implemented in an open fashion using the Amulet intrinsics so that researchers can replace or modify the widgets. The goal is that researchers will only have to implement the parts that they are interested in, relying on the Amulet library for everything else. In addition, we aim for Amulet to be useful for students and The Amulet Framework 2 Myers Object-Oriented Application Frameworks general developers. Therefore, we have tried to make Amulet easy to learn, and to have sufficient robustness, performance and documentation to attract a wide audience. Amulet, which stands for Automatic Manufacture of Usable and Learnable Editors and Toolkits (Myers 1997), is being developed as a research project at Carnegie Mellon University. It is implemented in C++ and runs on X/11, Windows 95, Windows NT, and the Macintosh. Applications created using Amulet can simply be recompiled to run on any of the machines.